1. Field of the Invention
The present invention is directed to improvements in computing systems and in particular to improvements in operability between application programming interfaces (APIs) and stored procedures interacting with the APIs when software upgrades or modifications are made to either one or both of the API and/or stored procedures.
2. Description of the Prior Art
Stored procedures are collections of pre-defined procedural code that are used to perform one or more tasks such as, for example, to access databases. There are a number of benefits in using stored procedures, including function encapsulation, performance enhancement, client-server processing, and security. Generally, a user explicitly invokes stored procedures in an interactive environment, but such procedures can also be invoked by other programs.
In today's software systems, an application may rely one or more of the stored procedures for various services. An application interfaces with the stored procedures or other applications through an application program interface (API). Such application integration allows an application to provide services without having to include the programming and data necessary to provide the services itself.
For example, a content management system (CMS) may rely on a database application for maintaining large amounts of information such as binary large objects (BLOBs) and character large objects (CLOBs). Stored procedures are utilized by the CMS to efficiently communicate with a database management system (DBMS). The CMS communicates with the stored procedures via a set of APIs in order to access the database information. The APIs are typically built in their own dynamic link library (DLL). The CMS may load the provided DLL and use the appropriate APIs for maintaining the BLOBs, CLOBs and other information stored in the database.
Software is typically upgraded periodically to include new or improved features. In the CMS example, the CMS and stored procedures may be independently updated in scheduled releases of new versions or maintenance levels. Each new update or release may include changes to the respective APIs, and the updates may be sent directly to a plurality of users. One problem that can result is that the updated APIs may not be inter-compatible between the CMS and the stored procedures when the CMS and stored procedures are at a different version or level with respect to each other. Such incompatibility may cause the CMS or the stored procedures to function incorrectly or not to function at all. For example, a stored procedure may only handle primitive data types such as integer, long, BLOB, and CLOB in the parameter passing portion of its interface. The stored procedure typically does not handle structured data of variable length such as, for example, an array of integers, an array of character strings or an array of mixed data types in the parameter passing of its interface.
To illustrate the problem further, in Content Manager Version 8 Release 1, an IBM product, this problem was solved with a pair of parameters (BLOB and CLOB), where the BLOB. contained numeric values representing the:                data element identifier,        data element type (i.e., small integer, integer, character),        data element length, and        data element value (for numeric data elements only).        
The CLOB contained the data element values of character elements. Common routines are invoked by both of the APIs and respective stored procedures to build and parse the BLOB/CLOB pair.
However, with a second release of Content Manager Version 8 (V8.2), it was necessary to add data elements to data structures being passed in BLOB/CLOB pairs. A problem is encountered because many customers can be running environments where APIs are at a different version/release levels than their stored procedures (e.g., the APIs are at level V8.1 and the stored procedures are at V8.2 or higher, and vice versa). There are two scenarios which present two distinct problems. In the first scenario, the APIs are at a lower version/release level than the stored procedures. In this first scenario, the stored procedures expect additional data elements at the end of a data structure, and attempt to parse them, but they are not there because the V8.1 APIs do not pass them, not having any knowledge of them.
In the second scenario, the APIs are at a higher version/release level than the stored procedures. In this scenario, the APIs pass additional data elements, elements of which the stored procedures have no knowledge. Both scenarios result in a parsing error according to the current method of building/parsing BLOB/CLOB pairs. This presents a continuing problem for future releases as elements are appended to data structures.
It is therefore desirable to provide an improved method and means of passing parameters for data structures where the API and the respective stored procedures are at different version or release levels.